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ABSTRACT 



A server provides media and telephony services in a tele- 
communications network. The server has a distributed, 
object-oriented software architecture, allowing client appli- 
cations to access resources located anywhere in the network. 
The server provides interfaces to media and telephony 
resources so that client applications, which may access the 
server through an IP data network, can access the resources. 
The software architecture framework is provided by Com- 
mon Object Request Broker Architecture (CORBA). The 
interfaces provided by the server are Interface Definition 
Language (IDL) application program interfaces (APIs) 
implemented using a distributed object model such as 
CORBA. 

30 Claims, 3 Drawing Sheets 
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ABSTRACT INTERFACE FOR MEDIA AND language-independent request to establish a session between 

TELEPHONY SERVICES me client and the server; transmitting from the client to the 

server an object-oriented, language-independent request to 

CROSS-REFERENCE TO RELATED establish a group containing the resource, the group corre- 

APPIJCAnONS 5 sponding to the session; and transmitting from the client to 

_ „ . „ me server an object-oriented, language-independent request 

-Ibis apphcatton is related to U.S. patent application Ser. to invokc a follction on the,resource. A method consistent 

No. 09/223,972 "Distributed Open Architecture for Media ^ ^ t invention butbsT ^ a parameter corre- 

and I Telephony Services," which is filed simultanseously sponding t0 me sessioQ for determining event callback 

with this application. 1Q behavion A me thod consistent with the present invention 

BACKGROUND OF THE INVENTION tote scis a parameter corresponding to the session for 

determining whether an event will be created. 

The present invention relates generally to a system and A client consistent with the present invention comprises 

method for providing media and telephony services in a means for transmitting to a server an object-oriented, 

telecommunications network and, more particularly, to an 15 language-independent request to establish a session between 

abstract interface for providing applications access to media the client and the server, means for transmitting to the server 

and telephony services in a distributed computing environ- an object-oriented, language-independent request to estab- 

ment. lish a group containing a resource, coupled to the server, the 

The demand for advanced telephony applications in tele- group corresponding to the session, and means for transmit- 

communications networks has grown significantly during 20 ting to the server an object-oriented, language-independent 

the past few years. The area of media and telephony request to invoke a function on the resource, 

applications, also referred to as computer telephony, Additional features and advantages of the present inven- 

includes a wide variety of application-specific devices, tion will be readily appreciated by one of ordinary skill in 

many of which have proprietary implementations. A diverse the art from the following detailed description of the best 

group of vendors develops, sells, and supports devices such 25 mode for carrying out the invention when taken in connec- 

as interactive voice response (IVR) systems, voice mail tion with the accompanying drawings, 
systems, e-mail gateways, fax servers, and automatic call 

distributors (ACDs). Many of these applications use emerg- BRIEF DESCRIPTION OF THE DRAWINGS 

ing technologies such as voice compression and expansion, pjo. 1 is a high-level block diagram of a system archi- 

text-to-speech translation, automatic speech recognition, 30 tecture consistent with the present invention; 

and facsimile-to-text translation. p, G 2 ^^3^ a high-level software architecture of a 

As telephony applications have become more numerous server consistent with the present invention; and 

and complex, interoperability problems have arisen. Further, fj G 3 illustrates a detailed internal structure of a media 

it is difficult to develop integrated applications that combine ^ consistent with the present invention and its interac- 

features of different application-specific devices because tions ^ applications and resources; 
they are developed by different vendors and often use 

proprietary software. Thus, a need arose for a framework for DETAILED DESCRIPTION OF THE 

developing telephony applications in which vendors agree PREFERRED EMBODIMENTS 

on certain aspects of implementation to allow interoperabil- ^ with the present invention allows 

ity of products and software. In response tothis need the devel t of appUcatioas and services in a modular 

Enterprise Computer TOephony Forum (ECTF) has defined manner and provides for grow th from a single node system 

such a framework. The ECTF framework provides foe to a ^ k node {q whkh ^ Hca . 

ability for computer telephony apptoauonsto share me4ia tions ^ ^ io Catcd on vario us ix)des throughout the system, 

resources (e.g., voice recognition). The ECTF has specified 4s ^ of ^ ^ ^ of media 

several apphcauon program mterfaces (APIs), including S^ ^ ers providing a deve lopment environment for telephony 

100, which defines an interface between a media server and applica £ onSj it s | ould 5e ^cialed that the invention has 

computer telephony applications. a broader poiGQiial applicatioil) and may be for devel- 

Media servers compliant with the ECTF S.100 API pro- opment of other applications, such as applications on the 

vide a means for developing computer telephony applica- 5Q World Wide Web. 

tions in an open client-server environment with shared p, G x mustrates a high-level block diagram of a system 
resources. The S.100 API is a hardware-independent and architecture consistent with the present invention. Network 
operating system-independent API. However, the S.100 API, 100 may ^ My type of ^ net work, including an Internet 
based on the C programming language, is a language depen- Protocol (IP) network. Server 100, which is a logical group- 
dent interface, which makes S.100 ultimately dependent on 55 of media jjrf telephony service 130, is 
the platform used. Also, current system architectures for coup i e d to network 100. Consistent with the present 
providing telephony services do not take full advantage of invention, media service 120 and telephony service 130 
object-oriented programming methods or use distributed prov id e interfaces to media and telephony objects that may 
processing, thus making it more difficult to extend architec- be located anywhere in network 100. Media service 120 and 
hires to include new components. Furthermore, current 6Q tel e p hony service 130 may be collocated on the same node 
system architectures with distributed components utilize or on DO des. Media services include services for 
proprietary protocols. media in teract i onSf ^ch as text-to-speech translation, inter- 
cttuuadv 00 tuc tkt\/tmtiam active voice response, and speech recognition and verifica- 
SUMMARY OF THE INVENTION don j^^/^^ inJ ude call control services (e.g., 

A method consistent with the present invention provides 65 making calls, taking calls, transferring calls, and joining 

access from a the client to a resource coupled to a server by calls) and transaction handling services (e.g., making SS7 

transmitting from the client to the server an object-oriented, Transaction Capabilities Application Part (TCAP) queries). 
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Media service 120 and telephony service 130 are also object using another vendor's ORB. An application devel- 

coupled to network 105, which may be any type of tele- oper is shielded from all details of the lower-level 

communications network, including a Public Switched Tele- interaction, including the locations of the objects and the 

phone Network (PSTN) or a private network. Media service marshaling (i.e., encoding to convert interfaces and param- 

120 and telephony service 130 arc coupled to network 105 5 cters into flattened message formats to transfer over a 

using adapters (not shown) specific to network 105. For network) and unmarshaling (i.e., decoding) of arguments, 

example, media service 120 can be connected to network Interface Definition Language (IDL) is essential to 

105 via a Dialogic Tl card. interoperability of components in a CORBA system. IDL is 

Application 140, coupled to network 100, uses the inter- a neutral intermediate language that specifies a component's 

face provided by access media service 120 and telephony 10 boundaries, interfaces with potential clients, or any descrip- 

service 130. Application 140 invokes methods on media tion of a resource or service that the server component wants 

service 120 and/or telephony service 130. Application 140 to expose to a client. IDL is not a programming language; it 

does not have to be collocated with media service 120 or is instead a language for expressing interfaces, 

telephony service 130, although the present invention does Several commercial implementations of the CORBAstan- 

not preclude the collocation of application 140 with either 15 dard exist. Orbix, developed by Iona Technologies, is one 

media service 120 or telephony service 130. SUCD implementation that may be used in methods and 

Media service 120, telephony service 130, and application systems consistent with the present invention: Orbix consists 

140 include processors 122, 132, and 142, respectively, and of a CORBA 2.0-compliant object request broker (ORB), an 

memories 124, 134, and 144, respectively. Processors 122, IDL compiler, and related tools. The ORB mediates between 

132, and 142 may be provided by conventional micropro- 20 clients and implementations of application objects and must 

cessor circuits. Memories 124, 134, and 144 may include provide a standard interface to such clients, and another to 

both RAM and ROM portions and may be implemented with such implementations of application objects. The CORBA 

any type of computer-readable medium, such as any standard does not specify whether the ORB is a set of 

electronic, magnetic, or optical read/write storage device. runtime libraries, a set of daemon processes, a server 

Memories 124, 134, and 144 store data that serves as 25 machine, or part of an operating system, 

instructions to processors 122, 132, and 142, respectively, Orbix is implemented as a pair of libraries — one for client 

and which, when executed by processors 122, 132, and 142, applications and one for servers — and the orbixd daemon, 

cause media service 120, telephony service 130, and appli- The orbixd daemon need only be present at nodes running 

cation 140 to carry out methods that are described below. ^ CORBA servers, and it is responsible for launching server 

processes dynamically. Because of the library implementa- 

System Architecture tion of 0rbix QRB there ^ QO central ^^0^ through 

FIG. 2 illustrates a high-level software architecture of which all object requests must pass. Instead, object requests 

server 110 consistent with the present invention. Server 110 pass directly from the client (application) code to the 

includes the following resources: media server 200, com- 35 invoked server object implementation. If the server and 

prising telephony services interface 210 and media services client are in different processes, the method invocation is 

interface 220; basic services portion 230; and system man- marshalled in the client process, transmitted over an IP 

agement portion 240. Server 110 also includes operating network, unmarshalled in the server process, and dispatched 

system services portion 250 and distributed software bus to the appropriate server object by the object adapter. The 

260. A software architecture consistent with the present ^ role of orbixd is to connect clients and servers for the first 

invention uses an object-oriented communication frame- time. Since Orbix adheres to HOP, the Orbix ORB can 

work that provides location-transparent communication interoperate with any other ORB that also supports the 

among the architectural components. The framework may standard IIOP. 

be provided, for example, by Common Object Request Another important component of Orbix is its compiler 

Broker Architecture (CORBA), an industry standard archi- 45 technology, which translates CORBA IDL into program- 

tecture developed by the Object Management Group (OMG) ming language code, e.g., C++, that performs remote calls, 

for systems integration. Details of CORBA can be found at The generated code is sufficiently sophisticated so that 

www.omg.org, which is hereby incorporated by reference. developers are not burdened with extra programming steps 

In general, CORBA brings together object-oriented com- after translation, 
puting and distributed computing. A CORBA-based system 50 Referring again to FIG. 2, operating system services 
is composed of cooperating objects on a software bus, which portion 250 provides an underlying architecture that sup- 
is called the object request broker (ORB). Each object has an ports server U0. Consistent with the present invention, 
interface, which in CORBA is an abstract, language- operating system 252 may be a UNIX operating system such 
independent representation of the set of methods that can be as AIX 4.15, which is built on open standards including 
understood by the object. Objects do not have to be collo- 55 UNIX 95, XPG 4, and X/Open. Server 110 also includes 
cated. Method invocations on remote objects occur through standards-compliant HTTP server 254, which, in conjunc- 
an underlying protocol, which can be specific to an ORB tion with graphical clients, provides a window into the 
vendor or based on an industry standard. Referring to FIG. system. High availability services 256 provide active and 
2, distributed software bus 260 is an ORB, through which standby lOBaseT or 100BaseT Ethernet network interface 
client applications interface with telephony services inter- 6 q cards (NIGs). For applications that do not tolerate a single 
face 210, media services interface 220, basic services por- point of failure, network traffic is automatically switched to 
tion 230, and system management portion 240. The ORB the standby NIC when failure of a NIC or external hub is 
enables objects to make requests and receive responses detected. Installation services 258 provide the ability to 
transparently in a distributed environment. install server 110 as a stand-alone unit or in a line-up. 

CORBA 2.0 specifies an interoperability protocol, Inter- 65 FIG. 2 also shows basic services portion 230, which 

net Inter-ORB Protocol (IIOP), that allows objects imple- provides basic services available to applications and 

mented using one vendor's ORB to communicate with an resources. CORBA name service 232 allows a resource 
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developer to place resources at specified locations and and may be a commercially available TTS server such as 
allows other resources to find and access those resources by Centigram's TruVbice® 5.1 or Eloquence Technologies 
name. CORBA name service 232 may be implemented, for Inc.'s Eloquent 2.0. Media server 200 accesses TTS server 
example, by OrbixNames, part of the Orbix product family. 284 through TTS API 272, which transports method requests 
CORBA event service 234 allows objects to communicate in 5 and responses and asynchronous events between media 
an event-driven style. The event service, which may be server 200 and TTS server 284. FIG. 3 also shows speech 
implemented using OrbixTalk, allows applications to deter- recognition/verification server 300, which may be a corn- 
mine which events are relevant to them and perform actions mercially available speech recognition and verification 
as required. The event service allows for decoupled design server such as Nuance's RecServer™. Media server 200 
between generating and receiving events, which simplifies 10 accesses speech recognition/verification server 300 through 
the implementation of object-oriented design and enhances speaker recognition API 278 and/or speaker verification API 
scalability. 280. 

Consistent with the present invention, basic services Speech recognition services may also be provided in 
portion 230 also includes resource administrator 236, which hardware/firmware by speech recognition component 298, 
provides network-wide tracking of resources, which can be 15 e.g., the Antares™ automatic speech recognition (ASR) 
shared among applications. When a resource becomes platform, commercially available from Dialogic®. Speech 
available, it registers with resource administrator 236 by - recognition component 298 may- be coupled to media 
providing information including type and, optionally, any adapter 296, e.g., Nuance's RecClient™, which provides a 
attributes or properties that distinguish it from other higher-level interface to speech recognition component 298. 
resources. Resources can query resource administrator 236 20 Media server 200 access speech recognition component 298 
for the existence of resources by interface type and an through speech recognition API 278, which accesses media 
optional list of properties. If several resources match a adapter 296 via an interprocess communication capability, 
particular type, resource administrator 236 balances Media server 200 may provide IVR service by accessing 
resource utilization by using a least-recently-used algorithm IVR component 290, which may be a commercially avail- 
to determine which resource to use, and favors local 25 able product such as Dialogic® D/240SC-T1. Media server 
resources over remote resources. 200 accesses IVR component 290 through basic IVR API 

Resource administrator 236 tracks resource owners for 274. IVR component 290 may be coupled to media adapter 

resource recovery. This reduces the amount of maintenance 288, which presents a higher-level interface to basic IVR 

required to attain a high level of system availability. API 274 and may be a commercially available product or a 

Resource administrator 236 also provides a first line of 30 proprietary API, e.g., a media adapter provided by Nortel 

security by allowing resources to access other resources only Server's Vail API. Media cache 286 provides cache storage 

if authorized to do so. for IVR applications. 

Resource administrator 236 may be a multi-tiered service, Hardware components coupled to media server 200 may 
including both local resource administrators and network- 35 communicate with each other via time division multiplexed 
wide administrators. In this case, a local resource admin is- (TDM) bus 302, which may be an SCbus™ compliant with 
trator tracks local, or nodal, resources, and queries a the Signal Computing System Architecture™ (SCSA) hard- 
network-wide administrator if it cannot satisfy a request. ware model, an industry standard TDM architecture. 

Media services interface 220 provides interfaces to media It should be apparent to one skilled in the art that the 

services including, for example, text-to-speech services ^ specific hardware components providing media or telephony 

(interface 222), speech recognition services (interface 224), services in FIG. 3 are exemplary only. Media server 200 may 

announcements/audio signals services (interface 226), and access any resource that provides functionality for a media 

facsimile services (interface 228). Telephony services inter- or telephony service. Also, as shown in FIG. 3, media server 

face 210 allows server 110 to interact with telecommunica- 200 may include API 276 for any application such as ASR, 

tions network 105 and provides interfaces to telephony 45 TTS, IVR, or facsimile, that accesses media adapter 292, 

services including, for example, system call router interface which accesses other hardware components connected to 

216 and interfaces to the SS7 signaling network (interface bus 302 via interface 294. 

212) and Tl/El signaling (interface 214). Detailed imple- Referring again to FIG. 2, server 110 includes system 

mentations of these interfaces consistent with the present management portion 240, which includes at least the fol- 

invention are discussed below. 50 lowing categories of system management based on the Open 

FIG. 3 illustrates a detailed internal structure of media Systems Interconnection (OSI) system management defini- 

server 200 and its interactions with applications and tion: fault management portion 242, configuration manage- 

resources consistent with the present invention. In order to ment portion 244, performance management portion 246, 

provide an interface to media services (interface 220) and to and security portion 248. System management portion 240 

telephony services (interface 210) as shown in FIG. 2, media 55 provides the APIs and user interfaces (UIs) for applications, 

server 200 accesses hardware components that provide the resources, network components, and hardware components 

functionality for such services. FIG. 3 shows several com- utilizing server 110 to be managed in a consistent and 

ponents that may be accessed by media server 200. For extensible manner. 

example, one telephony service that media server 200 may Fault management portion 242 provides a mechanism for 

access is server 282, which provides SS7 ISDN User's Part 60 generating, collecting, monitoring, and displaying fault 

(ISUP) signaling. SS7 ISUP application programming inter- events, such as logs and alarms. A fault event can be 

face (API) 270 translates messages from media server 200 generated, for example, by an IDL API that is part of 

into SS7 ISUP messages and communicates the SS7 ISUP telephony services interface 210 or media services interface 

messages to SS7 ISUP server 282. 220. Configuration management portion 244 provides 

FIG. 3 also shows several components that provide media 65 mechanisms for system installation; software distribution, 

services and may be accessed by media server 200. For which provides the ability to define, administer, and distrib- 

example, TTS server 284 provides text-to-speech translation ute software and configuration data; resource state 
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management, which allows applications and components application 140 as a custom piece of hardware including, for 

with the environment of server 110 to be managed from an example, speech recognition capability and recording capa- 

operations workstation and may be based on the ISO X.732 bility. More than one group can be established in one 

resource state model; and configuration (datafill) session, and application 140 can establish a connection 

management, which allows applications to define, generate, 5 between groups that allows data originating in a resource of 

and distribute configuration information and notify applica- one 8 rou P t0 t* received by a resource in another group, 
lions of configuration change events. Performance manage- Application 140 utilizes several IDL APIs consistent with 

ment portion 246 allows application to define, generate, mc present invention to establish and manage sessions, 

collect, store, and display performance measurement infor- S^P 5 ' connections. The SessionFactory IDL API is 

mation based on performance data generated by applications 10 usec L to J™?"* ™ e meth 1 od : 

using an IDL API and collected into a database. Security ^Session. When invoked by apphcation 140, this method 

portion 248 provides an interface to manage security infor- m *?* a new session and returns a pointer to the new 

mation such as user accounts and passwords. 56551011 ob ^ ™ e GroupFactory IDL API is used to create 

new groups of resources and contains two methods: 

Application-Server Interface 15 newGroup, called in synchronous mode, and 

newGroupAsync, called in asynchronous mode. Both meth- 

Implementations of telephony services interface 210 and 0 ds create a new group and hand it off to the session object 

media services 220 interface consistent with the present * specified by a parameter. The T session object must exist on 

invention will now be presented in more detail. Telephony the same media server as the newly created group. The 

services interface 210, shown in FIG. 2, allows application newGroup method returns a pointer to the new group object. 

140 to interact with telephone network 105 and provides a The ConnectionFactory IDL API is used to create new 

language -independent, location-independent, object- connections between groups and contains two methods: 

oriented interface to applications that require telephony newConnection, called in synchronous mode, and 

access to the network. Media services interface 220, also newConnectionAsync, called in asynchronous mode. Both 

shown in FIG. 2, allows application 140 to interact with methods can establish a one-way connection or a two-way 

media services, such as those provided by hardware com- connection between groups. 

ponents shown in FIG. 3, and provides a language- Consistent with the present invention, the methods of the 

independent, location-independent, object-oriented interface SessionFactory, GroupFactory, and ConnectionFactory IDL 

to applications that require access to media services. APIs are accessed through a main interface to media server 

More specifically, media services interface 220 and tele- ^ 200. This interface is referred to herein as the OMSServer 

phony services interface 210 consistent with the present IDL API and inherits from the SessionFactory, 

invention include IDL interfaces that allow applications to GroupFactory, and ConnectionFactory interfaces. The 

invoke the hardware resources connected to server U0. The OMSServer IDL API itself contains no methods. Another 

IDL interfaces are based on the ECTF S. 100 API, which is IDL, API the OMSServerFactory, contains one method, 

hereby incorporated by reference, but the IDL interfaces are 3S _new, that enables application 140 to acquire a handle to 

implemented using a distributed object model such as media server 200. 

CORBA. IDL interfaces consistent with the present inven- Once a session has been established, the Session IDL API 

tion are language-independent, whereas ECTF S.100 is provides a logical binding between application 140 and 

implemented in the C programming language. The IDL media server 200. As noted earlier, the session provides an 

interfaces that will be described may be part of either ^ event queue by which application 140 receives events from 

telephony services interface 210 or media services interface media server 200. An event is a key value set (KVS), which 

220. consists of a sequence of keys and values. All events have 

With reference to FIG. 3, all communication between the following standard keys, which are based on the standard 

application 140 and media server 200 occurs through a keys of the S.100 interface, and which describe components 

session, which enables application 140 to request functions 45 of the event message: 
from media server 200 and enables media server 200 to send 
events to application 140. A session provides an event queue 

by which application 140 receives events from media server ~~ 

200. Events notify application 140 of command responses, ^ Description 

execution errors, or changes in the system environment and 50 Message_ECTF_EventiD identifies the event. 

include at least two types: (1) completion events, which are Message_ECTF_Eveiit Qualifier Provides additional information to 

sent in response to a method call on an object, and (2) identif y ^ event 

*• * a , * u • .l Message__ECTF_ObiectID Identifies the object that 

unsolicited events, which occur in response to changes in the & J originated the event 

system environment. An application can invoke methods on Message jCTF-objectaass identifies the type of the ObjectiD 

objects in Synchronous mode, in which case the completion 55 Message_ECTF__Session[D Identifies the session to which 

event contains data requested by the method and is returned thc CVCIlt ™ delivered. 

A _ , , , . ,. , Message-ECTFUVCT Identifies the application context 

in an output parameter, or m asynchronous mode, in which 6 token of ^ ^JJ-^ 

case the completion event contains data requested by the Mcssage_ECTF__Status Identifies the error status in an 

method and error information. The event queue contains asynchronous request. 

both completion events and unsolicited events. Events can 60 Mes6age_ECTF_Errcr Identifies the error code in an 

be handled directly by the application or by event handlers Message _ECTF_SubError 3^^iJoSurror information 

associated with the event queue. in an asynchronous request. 

After establishing a session with media server 200, appli- Message^CTF_TrarisactionID Identifies the asynchronous request 

cation 140 may begin to perform media or telephony opera- associated with this event. 

lions using hardware resources such as those shown in FIG. 65 

3. Application 140 dynamically establishes a group contain- In addition, some methods trigger events that include event- 
ing one or more connected resources which appears to specific keys. 
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Data used by methods is in the form of a key value set 
(KVS), which contains a sequence of keys associated with 
values. For example, an event is a KVS that contains a 
sequence of event keys, where each event key represents an 
attribute of the event. Structurally, a KVS is a sequence of 
key value pairs (KVPairs). The sequence of KVPairs is 
stored in a KVSeq. 

The Session IDL API includes the following methods, 
which are based on similar methods specified in the EOF 
S.100 API, but are defined using IDL, thereby allowing for 
a platform-independent and language-independent imple- 
mentation: 

createHandler, described in IDL as: 

EventHandler createHandler (in KVSeq match, 

in Callback handler, 

in HCT net) 

raises (CTException); 
The createhandler method, called in synchronous mode, 
creates an event handler and specifies the criteria by which 
to filter events received in a session event queue. This 
method is based on the CTses_CreateHandler function of 
S.100. Events that match the criteria specified in the param- 
eter "match" are processed by this event handler; events that 
do not match are passed to another event handler or removed 
from the event queue. The parameter "handler" identifies the 
application object that is called when an event is matched. 
The parameter "net" identifies an application-defined token 
that is passed as an argument to the event handler. This 
method returns an event handler object and triggers an event 
that contains the standard event keys. Errors indicating that 
the combination of values for "match," "handler," and "her" 
is not unique are returned in CTException. 
createHandlerAsync, described in IDL as: 

oneway void createHandlerAsync (in KVSeq match, 

in Callback handler, 

in HCT net 

in CTuint tranld); 
The createHandlerAsync method, called in asynchronous 
mode, creates an event handler and specifies the criteria by 
which to filter events received in a session event queue. The 
equivalent function in S.100, CIses_CreateHandler, cannot 
be called in asynchronous mode. Events that match the 
criteria specified in the parameter "match'* are processed by 
this event handler; events that do not match are passed to 
another event handler or removed from the event queue. The 
parameter "handler" identifies the application object that is 
called when an event is matched. The parameter "bet" 
identifies an application-defined token that is passed as an 
argument to the event handler. The parameter "tranld** 
identifies an asynchronous context token that is returned in 
the completion event, enabling the completion event to be 
matched to the request. This method triggers an event that 
contains the standard event keys plus a key containing the 
newly created event handler. Errors indicating that the 
combination of values for "match," "handler " and "hct" is 
not unique are returned in the completion event. 
getParameters, described in IDL as: 

KVSeq getParameters (in Key Array keys, 

out KVSeq tranlnfo) 

raises (CTException); 
The getParameters method, called in synchronous mode, 
gets the current values of the session parameters. This 
method is based on the CTses_GetParameters function of 
S.100. The parameter "keys'* identifies the parameters for 
which to return values. The parameter "tranlnfo** contains 
the completion event that caused the method call to return. 
This method returns a key value pair for each returned 
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session parameter and triggers an event that includes the 
standard keys. A warning is returned if a key is specified that 
is not a session parameter. 
getParametersAsync, described in IDL as: 

5 oneway void getParametersAsync (in KeyArray keys, 
in CTuint tranld); 
The getParametersAsync method, called in asynchronous 
mode, gets the current values of the session parameters. This 
method is based on the CTses_GetParameters function of 

10 S.100. The parameter "keys'* identifies the parameters for 
which to return values. This method triggers an event that 
includes the standard keys phis a key containing key value 
pairs for each returned session parameter. If an error occurs, 
it is returned in the completion event key Message_ECTF_ 

15 Error. 

putEvent, described in IDL as: 

void putEvent (in KVSeq event). 

The putEvent method, called in synchronous mode, places 
an event on the session event queue for standard event 

20 processing. This method is based on the CTses_PutEvent 
function of S.100. The parameter "event'* contains the event. 
putEventAsync, described in IDL as: 

oneway void putEventAsync (in KVSeq event); 

25 The putEventAsync method, called in asynchronous mode, 
places an event on the session event queue for standard event 
processing. The equivalent function in S.100, CTses_ 
PutEvent function, cannot be called in asynchronous mode. 
The parameter "event** contains the event. 

30 setParameters, described in IDL as: 

void setParameters (in KVSeq parmList, 
out KVSeq tranlnfo) 
raises (CTException); 
The setParameters method, called in synchronous mode, sets 

35 the session parameters. This method is based on the CTses_ 
SetParameters function of S.100. The parameter "parmList" 
identifies a key value set of parameters for the session. An 
immediate handler key indicates whether events that match 
the handler's criteria will be called back immediately. An 

40 event options key indicates whether an event will be created 
or whether an event will be placed on event queue, or 
specifies which keys will be reported. Both the immediate 
handler option as well as the event options are enhancements 
to the S.100 standard. These enhancements consistent with 

45 the present invention allow the Media Server 200 to operate 
more efficiently. The parameter "tranlnfo" contains the 
completion event that caused the method call to return. This 
method triggers an event that includes the standard keys. A 
warning is returned if a key is specified that is not a session 

50 parameter. If a key has an invalid value, an error is returned 
in CTException. 

setParametersAsync, described in IDL as: 

oneway void setParametersAsync (in KVSeq parmList, 
in Cluint tranld); 

55 The setParametersAsync method, called in asynchronous 
mode, sets the session parameters. This method is based on 
the CTses_SetParameters function of S.100. The parameter 
"parmList" identifies a key value set of parameters for the 
session. An immediate handler key indicates whether events 

60 that match the handler's criteria will be called back imme- 
diately. An event options key indicates whether an event will 
be created or whether an event will be placed on event 
queue, or specifies which keys will be reported. This method 
triggers an event that includes the standard keys. If an error 

65 occurs, it is returned in the completion event keys Message^ 

ECTF_Error and Message ECTF SubError. 

waitEvent, described in IDL as: 



06/12/2003, EAST Version: 1.04.0000 



US 6,4< 

11 

CTbool waitEvent (in CTint timeout, 
out KVSeq tranlnfo) 
raises (CTException); 
The waitEvent method returns the next event from the 
session event queue, if an event is received within the time 
period specified by the parameter "timeout." This method is 
based on the CTses_WaitEvent function of S.100. The 
parameter "tranlnfo" contains the completion event that 
caused the method call to return. The method returns true if 
the event was received, and false otherwise. 
waitGroup, described in IDL as: 

Group waitGroup (out ACT act, 

in CTint timeout, 

out KVSeq tranlnfo) 

raises (CTException); 
The waitgroup method returns the next group that is 
received by the session, if a group is received within the time 
period specified by the parameter "timeout." This method is 
based on the CTgrp_WaitGroup function of S.100. The 
parameter "tranlnfo" contains the completion event that 
caused the method call to return. The parameter "act" 
contains the application context token of the group. The 
method returns the group received by the session. 

The CallBack IDL API is used to define callback objects, 
which are contained in event handlers. The callback object 
processes events. The server matches events to event han- 
dlers in reverse order of event handler creation. If an event 
matches an event handler, the server invokes the callback 
object of the matching event handler. The callback object 
returns a value that indicates whether the event requires 
further processing. The event is passed to matching event 
handlers until there are no more matching event handlers or 
the callback object indicates that the event requires no 
further processing. The callback object is implemented by 
providing code for the object in the client application. 

The CallBack IDL API includes the handle method, 
described in IDL as: 

boolean handle(inout KVSeq event, 
in HCT hct); 

The handle method processes an event received by the 
callback object. The parameter "event" identifies the event 
received by the callback object The parameter "hct" iden- 
tifies the handler context token of the event handler, speci- 
fied in the createHandler method of the Session interface. 

Once a group has been established within a session, the 
Group IDL API manages the allocation and configuration of 
resources into groups. The Group IDL API includes the 
following methods, which are based on similar methods 
specified in the ECTF S.100 API, but are defined using IDL, 
thereby allowing for a platform-independent and language- 
independent implementation. Similar to the Session IDL API 
methods described above, many functions actually have two 
methods, one called in synchronous mode and one called in 
asynchronous mode. The methods called in synchronous 
mode return the completion event in the output parameter 
"tranlnfo" and return errors in CTException. The methods 
called in asynchronous mode return errors in an event passed 
to the session. All parameters have the same meaning as 
those described in ECTF S.100, except as otherwise noted, 
allocate, described in IDL as: 
void allocate (in string resourceName, 

in CTint timeout, 

in KVSeq parmlist, 

out KVSeq tranlnfo) 

raises (CTException); 
The allocate method indicates to media server 200 that a 
configured resource is to be allocated to the group. Consis- 
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tent with the present invention, the parameter "resource- 
Name" identifies the resource to allocate to a group. An 
example of an accepted value is "NuanceRegognizer," 
which identifies the Nuance speech recognition resource. 

5 The parameter "parmlist" accepts, for example, key value 
pairs identifying the name of a speech recognition package 
that contains grammars defining utterances recognized by 
the speech recognition resource. The method triggers an 
event containing the standard event keys plus event-specific 

10 keys identifying a reference to the group and identifying an 
application context token. 
allocateAsync, described in IDL as: 
oneway void allocateAsync (in string resourceName, 
in long timeout, 

15 in KVSeq parmlist, 
in CTuint tranld); 
-This method is the -asynchronous version of the allocate 
method. The method triggers an event containing the stan- 
dard event keys plus event-specific keys identifying a ref- 

20 erence to the group and identifying an application context 
token. 

configure, described in IDL as: 

void configure (in string groupConfig, 
in ACT act, 
25 in CTint timeout, 

in KVSeq parmlist, 
out KVSeq tranlnfo) 
raises (CTException); 
The configure method configures dynamic resources allo- 
30 cated to a group. The method triggers an event containing 
the standard event keys plus event-specific keys identifying 
a reference to the group and identifying an application 
context token. 

configureAsync, described in IDL as: 

oneway void configureAsync (in string groupConfig, 

in ACT act, 

in CTint timeout, 

in KVSeq parmlist, 
^ in CTuint tranld); 

This method is the asynchronous version of the configure 
method. The method triggers an event containing the stan- 
dard event keys plus event-specific keys identifying a ref- 
erence to the group and identifying an application context 

45 tokcn * 

deallocate, described in IDL as: 

void deallocate (in string resourceName, 
in Clint timeout, 
in KVSeq parmlist 
50 out KVSeq tranlnfo) 
raises (CTException); 
The deallocate method indicates to media server 200 that a 
configured resource is to be deallocated from the group. The 
method triggers an event containing the standard event keys 
55 plus event-specific keys identifying a reference to the group 
and identifying an application context token. 
deallocateAsync, described in IDL as: 
oneway void deallocateAsync (in string resourceName, 
in CTint timeout, 
60 in KVSeq parmlist, 
in CTuint tranld); 
This method is the asynchronous version of the deallocate 
method. The method triggers an event containing the stan- 
dard event keys plus event-specific keys identifying a ref- 
65 erence to the group and identifying an application context 
token. 

getGroupInfo, described in IDL as: 
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KVSeq getGroupInfo (in KeyArray keys, KVSeq of key and value pairs where each key is a parameter 

out KVSeq tranlnfo) name and each value represents a parameter value. The 

raises (CTException); method triggers an event containing the standard event keys 

The getGroupInfo method obtains user information specific plus event-specific keys identifying a reference to the group 

to the group. The method returns a copy of the application 5 anc j identifying an application context token. 
KVSeq. The method triggers an event containing the stan- getParametersAsync, described in IDL as: 
dard event keys plus event-specific keys identifying a ref- getParametersAsync (in KeyArray keys, 

erence to the group and identifying an application context ^ CI\imt tranld) 

geSroupInfoAsync, described in IDL as: in ™* » asynchronous version of the getParameters 

oneway void getGroupInfoAsync (in KeyArray keys, 10 ™&od. The method triggers an event containing the stan- 
in CTuint tranld)' event keys plus event-specific keys identifying a ref- 

This method is the 'asynchronous version of the get- erenc* to the group, identifying an application context token, 
Grouplnfo method. The method triggers an event containing and identifying a «turn value, 
the standard event keys plus event-specific keys identifying getRTC, described in IDL as: 

a reference to the group, identifying an application context 1 KVSeq getRTC (out KVSeq tranlnfo) 
token, and identifying a return value. raises (CTException); 

getParameterNames, described in" IDL as: The getRTC method obtains the current runtime control 

KVSeq getParameterNames (in KeyArray keys, QKIQ setting on the group. The method returns a KVSeq 

out KVSeq tranlnfo) identifying the runtime controls on the group. The method 

raises (CTException); 20 triggers an event containing the standard event keys plus 
The getParameterNames method queries the existence of event-specific keys identifying a reference to the group and 
parameters for resources specific to the group. The method identifying an application context token, 
returns a KVSeq of key and value pairs where each key is getRTCAsync, described in IDL as: 

a parameter name and each value is true or false, indicating 25 oneway void getRTC Async (in Cluint tranld); 
whether the named parameter is supported by a resource in This method is the asynchronous version of the getRTC 
the group. The method triggers an event containing the method. The method triggers an event containing the stan- 
standard event keys plus event-specific keys identifying a dard event keys plus event-specific keys identifying a ref- 
reference to the group and identifying an application context erence to the group, identifying an application context token, 
token. and identifying a return value. 

getParameterNamesAsync, described in IDL as: handoff, described in IDL as: 

oneway void getParameterNamesAsync (in KeyArray void handoff (in string ASI, 

keys, in string tag, 

in CTuint tranld); in Clint timeout, 

This method is the asynchronous version of the getParam- 35 in KVSeq parmlist, 
eterNames method. The method triggers an event containing out KVSeq tranlnfo) 

the standard event keys plus event-specific keys identifying raises (CTException); 

a reference to the group, identifying an application context The handoff method passes a group to another session, 
token, and identifying a return value. During handoff, events received by the group are queued for 

getParameterRange, described in IDL as: ^ delivery to the session that controls the group at the comple- 

KVSeq getParameterRange (in KeyArray keys, tion of the handoff method call. The method triggers a 

out KVSeq tranlnfo) handoff event sent to the session initiating the handoff and 

raises (CTException); containing the standard event keys plus event-specific keys 

The getParameterRange method obtains the range of param- identifying a reference to the group and identifying an 

eter values for resources specific to the group. The method 45 application context token. The method also triggers an 
returns a KVSeq of key and value pairs where each key is arrival event sent to the session receiving the handoff and 
a parameter name and each value is either a single value, an containing the standard event keys plus event-specific keys 
array of values, or a numeric range, representing the range identifying a reference to the group and identifying an 
of possible values for the named parameter. The method application context token, 

triggers an event containing the standard event keys plus 50 handoffAsync, described in IDL as: 
event-specific keys identifying a reference to the group and void handoffAsync (in string ASI, 
identifying an application context token. in string tag, 

getParameterRangeAsync, described in IDL as: in Clint timeout, 

oneway void getParameterRangeAsync (in KeyArray in KVSeq parmlist, 

keys, 55 in CTuint tranld); 

in CTuint tranld); This is the asynchronous version of the handoff method. The 

This method is the asynchronous version of the getParam- events are the same as those triggered by the handoff 
eterRange method. The method triggers an event containing method. 

the standard event keys plus event -specific keys identifying putGroupInfo, described in IDL as: 

a reference to the group, identifying an application context eo void putGroupInfo (in KVSeq kvs, 

token, and identifying a return value. out KVSeq tranlnfo) 

getParameters, described in IDL as: raises (CTException); 

KVSeq getParameters (in KeyArray keys, The putGroupInfo method sets the contents of the group 

outKVSeq tranlnfo) KVSeq. The method triggers an event containing the stan- 

raises (CTException); 65 dard event keys plus event-specific keys identifying a ref- 

The getParameters method obtains the settings of parameters erence to the group and identifying an application context 

for resources specific to the group. The method returns a token. 
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putGroupInfoAsync, described in IDL as: setRTC, described in IDL as: 

oneway void putGroupInfoAsync (in KVSeq kvs, void setRTC (in KVSeq rtc, 

in CTuint tranld); out KVSeq tranlnfo) 

This method is the asynchronous version of the put- raises (CTException); 

Grouplnfo method. The method triggers an event containing 5 xhe setRTC method sets persistent group-level runtime 

the standard event keys plus event-specific keys identifying controls ( RTC ) that remain in effect for the duration of the 

a reference to the group and identifying an application group or ^ ^ melhod fc called again ^ tne 

context token. < (rtc „ V3rMQQt&t ^ t0 nu |j t The method triggers an event 

retrieve, described in 1UL as: containing the standard event keys plus event-specific keys 

void retrieve (m Key cause, 10 idemifying a reference to the group and identifying an 



application context token. 



i^SS) setRTCAsync, described in DDL as: 

raises (CTException); oneway void setRTCAsync (in KVSeq rtc, 

The retrieve method retrieves a group that has been handed in CTuint tranld); 

off without waiting for the group to be handed back by the This method is the asynchronous version of the setRTC 

current owning session. The method triggers an event con- method. The method triggers an event containing the stan- 

tainingthe standard event keys plus an event-specific key dard event keys plus event-specific keys identifying a ref- 

identifying'the reason for the group retrieval. erence to the group and identifying an application context 

retrieveAsync, described in IDL as: 2Q token. 

oneway void retrieveAsync (in Key cause, st0 P» described in IDL as: 

in Clint timeout, void stop(out KVSeq tranlnfo) 

in KVSeq parmList, raises (CTException); 

in CTuint tranld); The stop method causes all resources to stop current opera- 
This is the asynchronous version of the retrieve method. The 25 tion. The method triggers an event containing the standard 
method triggers an event containing the standard event keys event keys, 
plus an event-specific key identifying the reason for the stopAsync, described in IDL as: 
group retrieval. oneway void stopAsync (in CTuint tranld); 
returnGroup, described in IDL as: This is the asynchronous version of the stop method. The 
void returnGroup (in string tag, 30 method triggers an event containing the standard event keys, 
in CTint timeout, Once groups have been established within a session, 
in KVSeq parmList, ~ connections can be made between groups using the Con- 
outKVSeq tranlnfo) nection IDL API consistent with the present invention. The 
raises (CTException); Connection IDL API manages connections between groups. 
The returnGroup method returns a group to the previous 35 An active two-way connection can only be established 
owner on the owner stack. The method triggers an event between two groups. Once a two-way connection is 
containing the standard event keys plus event-specific keys established, any number of listening groups can be con- 
identifying a reference to the group and identifying an nected to either side of the two-party conversation. A lis- 
application context token. tening group has a connection that is configured to send data 
returnGroupAsync, described in IDL as: ^ only in one direction, from the existing group to the listening 
oneway void returnGroupAsync (in string tag, group. 

in CTint timeout, The Connection IDL API includes the following methods, 

in KVSeq parmList, which are based on similar methods specified in the ECTF 

in CTuint tranld; S.100 API, but are defined using IDL, thereby allowing for 

This method is the asynchronous version of the returnGroup 45 a platform-independent and language-independent imple- 

method. The method triggers an event containing the stan- mentation. Similar to the Session and Group IDL API 

dard event keys plus event-specific keys identifying a ref- methods described above, the Connection functions actually 

erence to the group and identifying an application context have two methods, one called in synchronous mode and one 

token. called in asynchronous mode. The methods called in syn- 

setParameters, described in IDL as: 50 chronous mode return the completion event in the output 

void setParameters (in KVSeq parmList, parameter "tranlnfo" and return errors in CTException. The 

out KVSeq tranlnfo) methods called in asynchronous mode return errors in an 

raises (CTException); event key. All parameters have the same meaning as those 

The setParameters method sets the parameters of the group. described in ECTF S.100, except as otherwise noted. 

The "parmList" parameter contains key and value pairs that 55 break, described in IDL as: 

identify parameters to set for each resource in the group. The void break (in CTuint dir, 

method triggers an event containing the standard event keys out KVSeq tranlnfo) 

plus event-specific keys identifying a reference to the group raises (CTException); 

and identifying an application context token. The break method deactivates a connection. The "dir" 

setParametersAsync, described in IDL as: 60 parameter indicates the direction of the connection to 

oneway void setParametersAsync (in KVSeq parmList, deactivate, from among (a) data flowing from a group to a 

in CTuint tranld; target, (b) data flowing from a target to a group, and (c) data 

This method is the asynchronous version of the setParam- flowing in both directions. The method triggers an event 

eters method. The method triggers an event containing the containing the standard event keys plus event-specific keys 

standard event keys plus event-specific keys identifying a 65 identifying the deactivated connection object, identifying 

reference to the group and identifying an application context the direction in which the connection was deactivated, and 

token. identifying an application context token. 
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breakAsync, described in IDL as: oneway void playAsync (in TVMArray tvmList, 

oneway void breakAsync (in CTuint dir, in long offset, 

in CTuint tranid); in KVSeq rtc, 

This method is the asynchronous version of the break in KVSeq parmList, 

method. The events are the same as those triggered by the 5 CTuint tranID); 

break method. This method is the asynchronous version of the play method, 

make, described in IDL as: The method triggers an event containing the standard event 

void make (in CTuint dir, keys plus event-specific keys identifying the reason the 

out KVSeq tranlnfo) event was generated and containing error codes, 

raises (CT Exception); jq The Recognizer interface allows an application to invoke 

The make method activates a connection. The "dir" param- the recognizer resource of a group to perform speech rec- 

eter indicates the direction of the connection to activate, ognition on a recorded speech sample. To use speech 

from among (a) data flowing from a group to a target, (b) recognition, an application makes a speech recognition 

data flowing from a target to a group, and (c) data flowing request, i.e., initiates speech recognition on a group that 

in both directions. The method triggers an event containing 15 contains a recognizer resource. The application retrieves the 

the standard event keys plus event-specific keys identifying result 0 f the request, which is returned as a string represent- 

the activated connection object, identifying the direction in fog the interpreted utterance. The Recognizer, interface also 

which the connection was activated, and identifying an allows an application to configure speech recognition 

application context token. grammars, which define the valid phrases recognized by the 

makeAsync, described in IDL as: 20 recognizer resource and are saved in a grammar specifica- 

oneway void makeAsyne (in CTuint dir, tion file. 

in CTuint tranid); The Recognizer interface includes the following methods: 

This method is the asynchronous version of the make contextCommit, described in IDL as: 

method. The events are the same as those triggered by the void contextCommit (in string resourceContext, 

make method. 25 m KVSeq parmList, 

Consistent with the present invention, media services out KVSeq tranlnfo) 

interface 220 of media server 200 includes IDL APIs that raises (CTException); 

enable application 140 to access various media resources. ^ cont extCommit method commits a dynamic grammar 

These interfaces includes the Player, Recognizer, Recorder, context to the recognition server resource. The method 

SignalDetector, and SignalGenerator, which can all be part 30 triggers an event containing the standard event keys, 

of a group. Each interface includes methods that are based contextCommitAsync, described in IDL as: 

on similar methods specified in the ECTF S.100 API, but are . , , . t . . . 

, £ , . .t_ i_ 11 r t\r oneway void contextCommitAsync (in string 

denned using IDL, thereby allowing for a platform- resourceContext 

independent and language-independent implementation. ^ KVSea parmList 

Similar to the IDL methods described above, many functions 35 t KVSea tranlnfo) 

actually have two methods, one called in synchronous mode (jj^iTranldl* 

and one called in asynchronous mode. The methods called in „ . A , , . ' , , . r . . 

, , J , . , . .... . This method is the asynchronous version or the context- 
synchronous mode return the completion event m the output „ . - ~, ' . , . . . . . . 

. «* t c » j * ™ Commit method. The method triggers an event containing 

parameter tranlnfo and return errors in CTException. The it _ A , , A . *** & 

r . , j . r the standard event keys, 

methods called m asynchronous mode return errors in an 40 4 ^ j , ■ rr . T 

4l A11 \ . . contextCopy, described in IDL as: 

event key. All parameters have the same meaning as those rJ 

described in ECTF S.100, except as otherwise noted. void contextCopy (in string containerContext, 

The Player interface allows an application to invoke the m s, ™g resourceContext, 

player resource of a group to play announcements during a m Direction direction, 

call and includes the following methods: 45 m pa™ 1 ^* > 

play, described in IDL as: out KVScc I tranlnfo) 

void play (in TVMArray tvmList, ^ raises (^xception); 

in long offset contextCopy method copies the contents of an existing 

in KVSeq rtc' recognition context into a container specified by the param- 

in KVSea parmList so eler acon t ame rContext," or the contents of a container into 

out KVSea tranlnfo) a recoS^tion context specified by the parameter "resource- 

M - 0 /rrc^a^.'J^. Context.** The parameter "direction" indicates the direction 

raises (Crhxceptionl; „ , . %_ , . . . 

Hie play method invokes the play function on media server of *f ***** ™ e method tn ^ ers an event contamm 8 the 

200. The parameter "tvmLisr identifies the announcement standard event keys 

files to be played. Ine parameter "offset" specifies the 55 contextCopyAsync, described in IDL as: 

number of bytes to skip forward from the beginning of each oneway void contextCopyAsync (in string 

file. The parameter "rtc" identifies key and value pairs for containerContext, 

non-persistent runtime control that contain actions for the m su ^g resourceContext, 

player resource, including pause, resume, and stop. The ^ Direction direction, 

parameter "parmList** identifies key and value pairs for 60 ™ KVSeq parmList, 

parameters of the player resource, such as the audio format m CTuint tranid; 

for announcements, e.g., the type of pulse code modulation This method is the asynchronous version of the contextCopy 

algorithm used. The method triggers an event containing the method. The method triggers an event containing the stan- 

standard event keys plus event -specific keys identifying the dard event keys. 

reason the event was generated, e.g., by runtime control or 65 contextCreate, described in IDL as: 

because the player resource reached the end of data to play. void contextCreate (in string resourceContext, 

playAsync, described in IDL as: in KVSeq parmList, 
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out KVSeq tranlnfo) parameters for the recognizer resource, including the length 

raises (CI 'Exception); of time to wait for speech, the maximum time to wait for a 

The context Create method creates a new recognition context valid utterance, and the length of silence to determine the 

that identifies a dynamic grammar used by application 140. end of speech. The method triggers an event containing the 

The method triggers an event containing the standard event 5 standard event keys, 

keys. startRecognitionAsync, described in IDL as: 

contextCreateAsync, described in IDL as: oneway void startRecognitionAsync (in KVSeq rtc, 

oneway void contextCreateAsync (in string in KVSeq parmList, 

resourceContext, in CTuint tranld); 

in KVSeq parmList, 1Q This method is the asynchronous version of the startRecog- 

in CTuint tranld; nition method. The method triggers an event containing the 

This method is the asynchronous version of the contextCre- standard event keys plus an event-specific key containing 

ate method. The method triggers an event containing the the error state of the recognizer resource, 

standard event keys. wordCreate, described in IDL as: 

contextRemove, described in IDL as: 1S void wordCreate (in string wordName, 

void contextRemove (in string resourceContext, in string wordString, 

in KVSeq parmList, in string resourceContext, 

out KVSeq tranlnfo) in KVSeq parmList, 

raises (CTException); out KVSeq tranlnfo) 

The contextRemove method removes a recognition context. 2Q raises (CJ Exception); 

The method triggers an event containing the standard event The wordCreate method adds word objects to a recognition 

keys. context to define the allowable words that are recognized. A 

contextRemove Async, described in IDL as: word object indicates the label and pronunciation associated 

oneway void contextRemoveAsync (in string with a spoken phrase. The 'SvordName" parameter identifies 

resourceContext, 25 the label of the word. The "wordString" parameter specifies 

in KVSeq parmList, the string associated with the word when the word is 

in CTuint tranld); recognized. The "resourceContext" parameter specifies the 

This method is the asynchronous version of the contextRem- name of the recognition context in which to create the word, 

ove method. The method triggers an event containing the The method triggers an event containing the standard event 

standard event keys. 30 keys. 

retrieveRecognition, described in IDL as: wordCreateAsync, described in IDL as: 

KVSeq retrieveRecognition (in ResultType resultType, oneway void wordCreateAsync (in string wordName, 

in KVSeq rtc, in string wordString, 

in KVSeq parmList, > in string resourceContext, 

out KVSeq tranlnfo) 35 in KVSeq parmList, 

raises (CTException); in CTuint tranld); 

The retrieveRecognition method retrieves the result of This method is the asynchronous version of the wordCreate 

speech recognition. The method returns key and value pairs method. The method triggers an event containing the stan- 

with the results of the speech recognition request. Results dard event keys, 

include a string value representing the spoken utterance, an 40 wordDestroy, described in IDL as: 

indication of whether natural language statements were void wordDestroy (in string wordName, 

specified in the selected grammar, strings representing the in string resourceContext, 

natural language interpretation, and a confidence value for in KVSeq parmList, 

the accuracy of the interpretation. The method triggers an out KVSeq tranlnfo) 

event containing the standard event keys. 45 raises (CTException); 

retrieveRecognitionAsync, described in IDL as: The wordDestroy method deletes a word from a recognition 

oneway void KVSeq retrieveRecognitionAsync (in context The method triggers an event containing the stan- 

Resultiype resultType, dard event keys. 

in KVSeq rtc, wordDestroyAsync, described in IDL as: 

in KVSeq parmList, 50 oneway void wordDestroyAsync (in string wordName, 

in CTuint tranld); in string resourceContext, 

This method is the asynchronous version of the retrieveRec- in KVSeq parmList, 

ognition method The method triggers an event containing in CTuint tranld); 

the standard event keys and event -specific keys containing This method is the asynchronous version of the wordDestroy 

the error state of the recognizer resource, a string value 55 method. The method triggers an event containing the stan- 

representing the spoken utterance, an indication of whether dard event keys. 

natural language statements were specified in the selected The Recorder interface allows an application to invoke 

grammar, strings representing the natural language me recorder resource of a group to record audio during a call 

interpretation, and a confidence value for the accuracy of the and includes the following methods: 

interpretation. 60 record, described in IDL as: 

startRecognition, described in IDL as: void record (in String tvm, 

void startRecognition (in KVSeq rtc, in KVSeq rtc, 

in KVSeq parmList, in KVSeq parmList, 

out KVSeq tranlnfo) out KVSeq tranlnfo) 

raises (CTException); 65 raises (CTException); 

Hie startRecognition method puts the recognizer resource in The record method invokes the record function on media 

recognizing state. The "parmList" parameter identifies server 200. Audio data is recorded on a channel associated 



06/12/2003, EAST Version: 1.04.0000 



US 6,4 

21 

with the specified group. The parameter "tvnT identifies the 
file in which to record audio data. The parameter "rtc M 
identifies key and value pairs for non-persistent runtime 
control that contain actions for the recorder resource, includ- 
ing pause, resume, and stop. The parameter "parmList" 
identifies key and value pairs for parameters of the record 
resource, such as the maximum duration to record, the 
maximum silence before the recorder resource stops 
recording, and the audio format for recording 
announcements, e.g., the type of pulse code modulation 
algorithm used. The method triggers an event containing the 
standard event keys plus event -specific keys identifying the 
reason the event was generated, e.g., by runtime control, 
because the recorder timer expired, because the silence 
threshold was reached, or because no speech was detected. 
recordAsync, described in IDL as: 

oneway void recordAsync (in String tvm, 
in KVSeq rtc, 
in KVSeq parmList, 
CTuint tranID); 
This method is the asynchronous version of the record 
method. The method triggers an event containing the stan- 
dard event keys plus event-specific keys identifying the 
reason the event was generated and containing error codes. 

The SignalGenerator interface allows an application to 
invoke the signal generator resource of a group to send dual 
tone multifrequency (DTMF) signals over a call channel and 
includes the following methods: 
sendSignals, described in IDL as: 

void sendSignals (in String signals, 
in KVSeq rtc, 
out KVSeq tranlnfo) 
raises (CTException); 
The sendSignals method instructs the signal generator 
resource to send the specified string of signals. The param- 
eter "rtc" identifies a key and value pair for non-persistent 
runtime control that contains a stop action. The method 
triggers an event containing the standard event keys plus 
event-specific keys identifying the reason the event was 
generated, e.g., by runtime control or by a stop command. 
sendSignals Async, described in IDL as: 

oneway void sendSignalsAsync (in String signals, 
in KVSeq rtc, 
CTuint tranID); 
This method is the asynchronous version of the sendSignals 
method. The method triggers an event containing the stan- 
dard event keys plus event-specific keys identifying the 
reason the event was generated and containing error codes. 

The SignalDetector interface allows an application to 
invoke the signal detector resource of a group to detect 
signals during a call and includes the following methods: 
flushBuffer, described in IDL as: 

void flushBuffer (out KVSeq tranlnfo) 
raises (CTException); 
The flushBuffer method instructs the signal detector 
resource to clear its internal signal buffer. The method 
triggers an event containing the standard event keys plus 
event-specific keys identifying the reason the event was 
generated, e.g., by runtime control. 
flushBufferAsync, described in IDL as: 

oneway void flushBuffer ( ); 
The flushBufferAsync is the asynchronous version of the 
flushBuffer method. The method triggers an event contain- 
ing the standard event keys plus event-specific keys identi- 
fying the reason the event was generated, e.g., by runtime 
control, and containing error codes. 
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retrieveSignals, described in IDL as: 
void retrieveSignals (in unsigned long numSignals, 
in unsigned long patterns, 
in KVSeq rtc, 

5 out KVSeq tranlnfo) 
raises (CTException); 
The retrieveSignals method instructs the signal detector 
resource to begin detecting signals. If buffering is enable, 
then detected signals are stored in a signal buffer and 

10 matched against user-defined patterns or templates. The 
"numSignals" parameter specifies the number of signals to 
detect. The "patterns" parameter specifies a bitmask of 
patterns that detected signals must match in order for the 
method call to complete successfully. The parameter "rtc" 
identifies key and value pairs for non-persistent runtime 

15 control that contain a flush buffer action and a stop action. 
The "parmList" parameter identifies key value pairs includ- 
ing a string defining a pattern, an initial time-out threshold, 
a time-out threshold during detection, a maximum duration 
for receiving signals, an indicator of which signal reporting 

20 events are enable, an indicator of whether the oldest signal 
in the buffer should be discarded when the buffer is full, and 
an indicator of whether internal buffering is enabled. The 
method triggers an event containing the standard event keys 
plus event-specific keys identifying the reason the event was 

25 generated, e.g., by runtime control, by a stop command, by 
a timeout on the completion of matching patterns, by a 
timeout on the initial detection, by a timeout during detec- 
tion of successive signals, because the requested number of 
signals was received, or by indicating which pattern was 

3 q matched. 

retrieveSignalsAsync, described in IDL as: 

oneway void retrieveSignalsAsync (in unsigned long 
numSignals, 

in unsigned long patterns, 
35 in KVSeq rtc, 
CTuint tranID); 
This method is the asynchronous version of the retrieveS- 
ignals method. The method triggers an event containing the 
standard event keys plus event-specific keys identifying the 
40 reason the event was generated and containing error codes. 
Consistent with the present invention, media services 
interface 220 of media server 200 includes IDL APIs for 
text-to-speech resources that are not part of a group. The 
TextToSpeech interface, which converts text into an audio 
45 file, and TextToSpeechFactory interface, which creates new 
TextToSpeech objects and acquires a handle to the text-to- 
speech server, include methods that are based on similar 
methods specified in the ECTF S.100 API, but are defined 
using IDL, thereby allowing for a platform-independent and 
50 language -independent implementation. 

The TextToSpeech interface includes the method 
convertToSpeech, described in IDL as: 
void convertToSpeech (in string text, 
in string container, 
55 in KVSeq parmList) 
raises (CTException); 
The convertToSpeech method converts the text specified in 
the parameter "text" to audio data stored in the file specified 
by the parameter "container." The "parmList" parameter 
60 identifies a key value set of parameters for specifying the 
pitch of the announcement, the speed of the announcement, 
the voice to use, the volume of the generated audio file, the 
type of pulse code modulation to use, and the language. 
The TextToSpeechFactory interface includes the 
65 method_ new, described in IDL as: 

static TextToSpeech ptr_new (const char* 

containerRoot, 
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TextToSpeechFactory::iype ttstype); in KVSeq parmlist, 

The method jew creates a new TextToSpeech object. The in CTuint tranld); 

parameter "containerRoot" indicates the directory where This method is the asynchronous version of the dropCall 

audio files specified with a relative path will be stored. The method. The method triggers an event containing the stan- 

" ttstype** parameter specifies the type of TextToSpeech 5 dard event keys. 

object to create, depending on the text-to-speech conversion makeCall, described in IDL as: 

package used, e.g., Centigram or Eloquent. The method Group makeCall (in Session session, 

returns TextToSpeech_ptr, a pointer to the new in string destAddress, 

TextToSpeech object. in string ASI, 

Consistent with the present invention, telephony services 1Q in string config, 

interface 210 of media server 200 includes IDL APIs that in Clint timeout, 

enable application 140 to access telephony resources avail- in KVSeq parmlist, 

able in network 105. In particular, the SystemCallRouter out KVSeq tranlnfo) 

interface provides call control tasks for application 140, raises (CTException); 

such as answering inbound calls, making outbound calls, 15 The makeCall method places an outbound call, which is 

configuring dynamic resources for a group, configuring a handed to a session. The "ASI" parameter identifies the 

line device for outbound calls, providing an interface for application service ID (ASI) of the session to take control of 

group handoff using application service IDs, and transfer- the call. If no value is specified for the "ASI" parameter, the 

ring calls out of the media server. The SystemCallRouter "session" parameter identifies the session to take control of 

interface includes methods that are based on similar methods 2Q the call. The "destAddress" parameter is the dialable address 

specified in the ECTF S. 100 API, but are defined using IDL, for the outbound call. The "timeout" parameter specifies a 

thereby allowing for a platform-independent and language- time to wait for the call to complete. The method triggers an 

independent implementation. Similar to the IDL methods event containing the standard event keys plus event-specific 

described above, the functions actually have two methods, keys for identifying the group containing the call, identify- 

one called in synchronous mode and one called in asynchro- 25 ing the destination address dialed, and identifying the origi- 

nous mode. The methods called in synchronous mode return nating address used, 

the completion event in the output parameter "tranlnfo" and makeCallAsync, described in IDL as: 

return errors in CTException. The methods called in asyn- Group makeCallAsync (in Session session, 

chronous mode return errors in an event key. All parameters m string destAddress, 

have the same meaning as those described in ECTF S.100, 3Q m string ASI, 

except as otherwise noted. m string CO nfig, 

The methods of the SystemCallRouter interface are m CTint timeout, 

accessed through the OMSServer interface, which inherits m KVSeq parmlist, 

from the SystemCallRouter interface. The SystemCall- m CTuint tranld); 

Router interface includes the following methods: 35 This method is the asynchronous version of the makeCall 

answerCall, described in IDL as: method. The method triggers an event containing the stan- 

void answerCall (in Group, group, dard event keys plus event-specific keys for identifying the 

in CTint timeout, group containing the call, identifying the destination address 

in KVSeq p arm List, dialed, identifying the originating address used, and provid- 

out KVSeq tranlnfo) 43 ing call analysis for a completed call, e.g., a connection was 

raises (CTException); established, a voice was detected, or an answering machine 

The answerCall method answers an incoming call. The was detected. 

"group" parameter identifies the group that contains the call. requestGroup, described in IDL as: 

The method triggers an event containing the standard event void requestGroup (in Session session, 

keys. 45 in string ASI, 

answerCallAsync, described in IDL as: m ACT act, 

oneway void answerCallAsync (in Group, group, in KVSeq parmlist, 

in CTint timeout, out KVSeq tranlnfo); 

in KVSeq parmlist, The requestGroup method registers the session as a target for 

in CTuint tranld); 50 groups handed of! to an application service ID (ASI) using 

This method is the asynchronous version of the answerCall the handoff ( ) method in the Group interface. The "parm- 

method. The method triggers an event containing the stan- List" parameter identifies key value pairs including the 

dard event keys. number of groups requested, a port number on which to 

dropCall, described in IDL as: request groups, the originating phone number on which to 

void dropCall (in Group, group, 55 request groups, and the state of the call (e.g., when call is 

in CTint timeout, answered or when call is ringing) when the system call 

in KVSeq p arm List, router hands the group to a session. The method triggers an 

out KVSeq tranlnfo) event containing the standard event keys 

raises (CTException); requestGroupAsync, described in IDL as: 

The dropCall method drops an incoming call but retains 60 void requestGroupAsync (in Session session, 

ownership of the group. The "group" parameter identifies in string ASI, 

the group encapsulating an active call. The "timeout" param- in ACT act, 

eter specifies a time to wait for the call to drop. The method in KVSeq parmUst, 

triggers an event containing the standard event keys. in CTuint tranld); 

dropCallAsync, described in IDL as: ss This method is the asynchronous version of the request- 
oneway void dropCallAsync (in Group, group, Group method. The method triggers an event containing the 
in CTint timeout, standard event keys. 
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It will be appreciated by those skilled in this art that 
various modifications aod variations can be made to the 
language-independent, object-oriented interface for provid- 
ing media and telephony services described herein without 
departing from the spirit and scope of the invention. Other 5 
embodiments of the invention will be apparent to those 
skilled in this art from consideration of the specification and 
practice of the invention disclosed herein. It is intended that 
the specification and examples be considered exemplary 
only, with a true scope and spirit of the invention being 1Q 
indicated by the following claims. 

We claim: 

1. A method for providing access from a client to multiple 
resources, coupled to a server, comprising: 

transmitting from the client to the server an object- 
oriented, language-independent request to establish a 15 
session between the client and the server; 

transmitting from the client to the server object-oriented, 
language-independent requests to establish multiple 
groups containing the resources, the groups corre- 
sponding to the session; and 20 

transmitting from the client to the server, an object- 
oriented, language-independent request to invoke at 
least a function on the resources. 

2. The method of claim 1 wherein transmitting a request 

to establish a session includes 25 
setting a parameter corresponding to the session for 
determining event callback behavior. 

3. The method of claim 1 wherein transmitting a request 

to establish a session includes 3Q 
setting a parameter corresponding to the session for 
determining whether an event will be created. 

4. The method of claim 1 wherein transmitting a request 
to establish a session includes 

setting a parameter corresponding to the session for 35 
determining whether an event will be placed on an 
event queue. 

5. The method of claim 1 wherein transmitting a request 
to establish a session includes 

setting a parameter corresponding to the session indicat- 40 
ing whether an event key should be reported to the 
client. 

6. The method of claim 1, wherein a second resource is 
coupled to the server, the method further comprising 

transmitting from the client to the server an object- 45 
oriented, language-independent request to establish a 
second group containing the second resource, the sec- 
ond group corresponding to the session; and 

transmitting from the client to the server an object- 
oriented, language-independent request to establish a 50 
connection between the first group and the second 
group. 

7. The method of claim 1 wherein the resource is an 
announcement player and wherein transmitting an object- 
oriented, language-independent request to invoke a function 55 
on the resource includes transmitting a request to invoke a 
play function on the announcement player. 

8. The method of claim 1 wherein the resource is a speech 
recognition device and wherein transmitting an object- 
oriented, language-independent request to invoke a function 60 
on the resource includes transmitting a request to invoke a 
start function on the speech recognition device. 

9. The method of claim 1 wherein the resource is a speech 
recognition device and wherein transmitting an object- 
oriented, language-independent request to invoke a function 65 
on the resource includes transmitting a request to invoke a 
retrieve function on the speech recognition device. 
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10. The method of claim 1 wherein the resource is a signal 
generator and wherein transmitting an object-oriented, 
language-independent request to invoke a function on the 
resource includes transmitting a request to invoke a send 
function on the signal generator. 

11. The method of claim 1 wherein the resource is a signal 
detector and wherein transmitting an object-oriented, 
language-independent request to invoke a function on the 
resource includes transmitting a request to invoke a retrieve 
function on the signal detector. 

12. The method of claim 1 wherein the resource is a 
text-to-speech converter and wherein transmitting an object- 
oriented, language-independent request to invoke a function 
on the resource includes transmitting a request to invoke a 
convert function on the text-to-speech converter. 

13. The method of claim 1 wherein the resource is a 
system call router and wherein transmitting an object- 
oriented, language-independent request to invoke a function 
on the resource includes transmitting a request to invoke an 
answer function on the system call router. 

14. The method of claim 1 wherein the resource is a 
system call router and wherein transmitting an object- 
oriented, language-independent request to invoke a function 
on the resource includes transmitting a request to invoke a 
function on the system call router to make a call. 

15. The method of claim 1 wherein the resource is a 
system call router and wherein transmitting an object- 
oriented, language-independent request to invoke a function 
on the resource includes transmitting a request to invoke a 
function on the system call router to drop a call. 

16. A client comprising: 

means for transmitting to a server an object-oriented, 
language-independent request to establish a session 
between the client and the server; 

means for transmitting to the server object-oriented, 
language-independent requests to establish multiple 
groups containing resources, coupled to the server, 
each group corresponding to the session; and 

means for transmitting to the server object-oriented, 
language-independent requests to invoke at least a 
function on the resources. 

17. The client of claim 16 wherein the means for trans- 
mitting a request to establish a session includes 

means for setting a parameter corresponding to the ses- 
sion for determining event callback behavior. 

18. The client of claim 16 wherein the means for trans- 
mitting a request to establish a session includes 

means for setting a parameter corresponding to the ses- 
sion for determining whether an event will be created. 

19. The client of claim 16 wherein the means for trans- 
mitting a request to establish a session includes 

means for setting a parameter corresponding to the ses- 
sion for determining whether an event will be placed on 
an event queue. 

20. The client of claim 16 wherein means for transmitting 
a request to establish a session includes 

means for setting a parameter corresponding to the ses- 
sion indicating whether an event key should be reported 
to the client. 

21. The client of claim 16 further comprising 

means for transmitting to the server an object-oriented, 
language-independent request to establish a second 
group containing a second resource, coupled to the 
server, the second group corresponding to the session; 
and 

means for transmitting to the server an object-oriented, 
language-independent request to establish a connection 
between the first group and the second group. 
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22. The client of claim 16 wherein the resource is an 27. The client of claim 16 wherein the resource is a 
announcement player and wherein the means for transmit- text-to-speech converter and wherein the means for trans- 
ting an object-oriented, language-independent request to mitting an object-oriented, language-independent request to 
invoke a function on the resource includes means for trans- mvoke a fo^on on t h e resource includes means for trans- 
mitting a request to invoke a play function on the announce- 5 miuing a to mvoke a CQnvert on the 

mC ^^ yC i- ♦ c i • « u • >u * u text-tOHspeech converter. 

23. The client of claim 16 wherein the resource is a speech „ • r „ t c . . _ , . . • * 

..... • • • ,m r . v.. 28. The client of claim 16 wherein the resource is a system 

recognition device and wherein the means for transmitting * ' ... _ . . J 

an object-oriented, language-independent request to invoke can router and wherein the means for transmitting an 

a function on the resource includes means for transmitting a to object-oriented, language-independent request to invoke a 

request to invoke a start function on the speech recognition function on the resource includes means for transmitting a 

device. request to invoke an answer function on the system call 

24. The client of claim 16 wherein the resource is a speech router. 

recognition device and wherein the means for transmitting 29. The client of claim 16 wherein the resource is a system 

an object-oriented, language-independent request to invoke is calI router and w hcrein the means for transmitting an 

a function on the resource includes means for transmitting a object-oriented, language-independent request to invoke a 

niUordevi^ 0 ^ a rctnCVe ° D ° D rcC ° g " fUDCti0n 0n reSOUfC * " indudcs meanS f ° r transmittlD S a 

^ThrcHent of claim 16 wherein the resource is a signal rec * uest ^ invoke a function on the system call router to 

generator and/wherein the means for transmitting an object- 20 maKe a caAA * 

oriented, language-independent request to invoke a function 30 ™c client of claun 16 wherein resource 15 a 

on the resource includes means for transmitting a request to cal1 router and wherein the means for transmitting an 

invoke a send function on the signal generator. object-oriented, language-independent request to invoke a 

26. The client of claim 16 wherein the resource is a signal function on the resource includes means for transmitting a 

detector and wherein the means for transmitting an abject- 25 request to invoke a function on the system call router to drop 

oriented, language-independent request to invoke a function a call, 
on the resource includes means for transmitting a request to 

invoke a retrieve function on the signal detector. + + * * + 
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